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Method and apparatus for long term verirication of digital signatures 



(57) The lime over which a digital signature can be 
verified is extended well beyond the expiration of any or 
all of the certificates upon which thai signature depends. 
In a "save state" approach, an archive facility Is used to 
store public key infrastructure (PKI) state, e.g, crypto- 
graphic Information, such as certificates and certificate 
revocation lists (CRLs), in addition to ndn-ciyptographic 
information, such as trust polby statements or the doc- 
ument Itself. This information comprises all that is nec- 
essary to re-create the signature verification process at 
a later time. When a user wants to verify the signature 
on a document, possibly years later, a long term signa- 
ture verification (LTSV) sender re-creates the precise 



state of the PKI at the time the document was origrnaify 
submitted. The LTSV sen/er restores the state, and the 
signature verification process executes the exact "proc- 
ess it performed (or would have performed) years ear- 
lier. Another embodiment of the invention combines the 
strength of cryptography with the proven resilience of 
(non-public key) technology and procedures currently 
associated with secure data stores by saving the PKI 
slate for future verificaliori; and protecting the PKI state 
information from Intrusion by maintaining it in a secure 
storage facility which is protected by sen^ices. such as 
firewalls, access control mechanisms, audit facilities, in- 
trusion detection faciifties, physical Isolation, and net- 
work isolation. 
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Description 

This invention relates to a method and apparatus 
for the long term verification of digila! signatures. 

The technology of digital signatures opens up the 
likelihood of increased use of digital networks (including 
the Internet) lor electronic commerce. It is now feasible 
to send and receive digitally signed documents that rep- 
resent transactions of some value to one or more par- 
ties. 

Currently, a digital signature is verifiable only as 
long as the digital certificates upon which it depends 
have not expired. Given the expectatbn that a certifi- 
cate's life span is in the area of one to tvwo years dura- 
tion, current technology does not support the emerging 
neecte of the electronic commerce market, where the du- 
rability of digital signatures over time is a requirement. 

For certain applksations, the recipient of digitally 
signed documents should be able to verify the authen- 
licily o( a documenl years afler Ihe document was 
signed, jus! as the document's authenticity can be ver- 
ified at the time of signing. Unfortunately, the current 
state of the technology does not provide tor the verifica- 
tion of these digital signatures after certificate expiration 
because it is the nature of keys and certificates used for 
signing and encrypting documents to expire afler a spe- 
cific period of time (typically after a year or two). This is 
due, at least in part, to the fact that the strength of keys 
is expected to degrade over lime because of such fac- 
tors as improvements in computing speed and break- 
throughs in ciyptoanalysis. r^reover. the tonger the key 
is in use, the longer that an adversary has to attempt to 
crack the key. Therefore, it is standard practice to re- 
place keys periodically. This is why certificates have 
specific expiration dates. 

An examinatton of the current state of the technol- 
ogy reveals that a digital signature verification module 
would fail if presented with a request to verify a signed 
document in which any of the associated certificates had 
expired. Fig. 1 is a block schemata diagram illustrating 
certification expiratkm. This simple example demon- 
strates that, given a certificate 10 having a two-year life 
span (e,g. from 4/1/96 to 4/1/98). a signature could be 
successfully verified six months (e.g. on IO/i/96) after 
certificate issuance (1 00); but this same signature would 
not be successfully verified three years later (e.g. on 
4/1/99) (102). This behavior Is clearly unacceptable If 
the duration ol a documenl, for example contract, must 
extend beyond the duration of the certificates' lile. 

Further, some current systems use certificate revo- 
cation lists (CRLs) to revoke certificates and remove 
them therefrom, once those certificates expire. This 
means that a record of those CRLs generally disap- 
pears» making long term signature verification impossi- 
ble using known techniques. 

It is known to reconstruct past trust (see A. Menez- 
es, P. van Oorschot. S. Vanstone. Handbook of Applied 
Cn^ptooraphv. CRC Press, pp. 583 (1996)). In this ap- 



■ proach. both signature reverificatkm relative to a past 
point in time and resolution of disputes may require re- 
construction of chains of trust from a past point in time. 
This requires archival of keying material arid related In- 

s formation for reconstruction of past chains of trust. Di- 
rect reconstruction of such past chains is taught to be 
unnecessary if a notarizing agent is used. A notarizing 
agent is defined as a general service capable not only 
of ascertaining the existence of a document at a certain 

10 time, but of vouching for the truth of more general state- 
ments at certain points in lime. The original verificatmn 
of the notary is taught to establish the existence of a 
trust chain at that point in time, and subsequently its 
record thereol is taught to senre as proof of prior validity. 

IS 11 Is taught that details of the original trust chain may be 
recorded for audit purposes. It is not taught that a doc- 
ument can be verified based upon the existence ol ex- 
pired certificates. Rather, reliance is placed upon the 
use of the notarizing agent. It is further taught that the 

20 archived keying material can be used as evidence al a 
future time to allow resolution of disputed signatures by 
non-automated procedures. 

It woukJ be advantageous to provide a technique for 
extending the time over which the authenticity and in- 

2S tegrity ol digital signaturescan be accurately verified be- 
yond the time that any relevant certificates expire. 

The present invention seeks to provide improved 
signature verification. 

According to an aspect of the present invention 

30 there is provided a method of enabling long term verifi- 
cation of digital signatures as specified in claim 1. 

/^cording to another aspect of the present inven- 
tion there is provided apparatus as specified in claim 11 . 
The prefered embodiment provides a method and 

3S appariatus which effectively extends the time over which 
a digital signature can be verified. Le, well beyond the 
expiration of any or all of the certificates upon which that 
signature depends. The invention can be used for any 
applrcation domain where users want digital signatures 

40 to be applied to bng lasting documents (e.g. contracts), 
and be independently verifiable years or decades after 
signing the document. The preferred embodiment pro- 
vides two alternative approaches to constructing a so- 
lution which delivers tong term signature verification 

4S (LTSV). 

One embodiment of the invention provides an ap- 
proach for solving the LTSV problem that is referred to 
herein as the "save stale" approach. This embodiment 
of the inventbn largely entails the use of cryptographic 

so information and techniques. Thus, an archive facility is 
used to store the publto key infrastructure (PKt) state, 
e.g. cryptographic information, such as certificates and 
CRLS, in addition to the document iteelf. This Informa- 
tion comprises all that is necessary to re-create the sig- 

ss nature verification process at a later time. It may also be 
desirable to store the source document separately from 
the cryptographic information (such as the signature, 
certificates, and CRLs) for reasons of privacy. For ex- 
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ample, a user may want to have control over the source 

document. The PKI state information may contain either 
or both of cryptographlcally protected Information, such 
as certificates and CRLs, and information that is not 
cryptographlcally protected, such as the public key of a 
root certification authority or policy hformation. 

When a user wants to reve/ify the signature on a 
document, possibly years later, an LTSV sender re-cre- 
ates the precise state of the PKI at the time the docu- 
ment was originally submitted. The LTSV sen/er re- 
stores the state, and the sigr^ture verification process 
executes the exact process it performed (or would have 
performed) years earlier The lime used as the basis for 
re-crealionof the signature verification process does not 
have to be the time of submittal. Rather, the time could 
be some other relevant time, such as when a document 
was signed by the originator or when it was verified by 
a recipient. 

Another embodiment of the invention combines the 
strength of cryptography with the proven resilience of 
(non-public key) technology and procedures currently 
associated with secure data stores. An example of this 
embodiment provides a mechanism that: 

• Saves the PKI state for future reverification; and 

• Protects the PKIvstate infornDation from intrusion by 
either nrYalntatning It in a secure storage facility 
which Is protected by services, such as firewalls, ac- 
cess control mechanisms, audit facilities, intrusion 
detection facilities, physical isolation, and network 
isolation; and/or employing a cryptographic protec- 
tion mechanism, for exaniple using the LTSV sen/er 
to sign the PKI state information or using a keyed 
hash algorithm. 

In addition, other non-cryptographic features may 
be added to such approaches to deliver a highly secure 
and trusted LTSV solution, including, for example utili- 
ties for viewing the PKI state information (cryptographic 
as well as non-cryptographk:) and visually monitoring 
the security ol the system. These utilities can be used 
to provide visual evidence for purposes of dispute res- 
olution. 

One enhancement to the secure storage approach 
herein disclosed maintains certain evidence, such as 
certificate chains, in an archive. This informatkx) need 
not be used for actual reverification. but merely as sup- 
porting evidence in case of a dispute. 

An embodiment of the present inventbn is de- 
scribed below, by way of example only, with reference 
to the accohipanying drawings, in which: 

Fig. 1 is a block schematic diagram illustrating cer- 
tification expiration; 

Fig. 2 is a block schematic diagram illustrating a 
"save state' embodiment of the Invention; 



Fig. 3 Is a bbck schematic diagram illustrating a 
"save stale" "secure storage^ embodfanent of the In- 
vention: 

5 Fig. 4 is a flow diagrarn that provides two alternative 
scenarios that illustrate the applicabifity of time 
stamps to the preferred embodimevils; 

Figs. 5a-5c provide btock schematic diagrams that 
10 illustrate three long term signature verification us- 
age scenarios; . 

Fig. 6 is a btock schematic diagram that illustiates 
trust between two entities ; and 

IS 

Fig 7 Is a bkx;k schematic diagram that illustrates 
a long term signature verification trust model. 

The meanings of some of the terms used herein 

20 rnay differ somewhat from common usage. The follow- 
ing definitions are meant to clarify the meaning of each 
in the context of its usage herein. 

Archive: Any facility for the storage and retrieval of 
electronic infonnation. 

2S Certificate: An artifact upon which digital signatures 
are based. A certificate securely binds an entity with that 
entity's public key. 

Cryptographic Refresh: A means of solving the key 
degradation problem when storing cryptographic infor- 

SO matton for long periods of time. The process involves 
re-encoding the old cryptographic artifacts (e.g: en- 
crypted data, digital signatures, and message digests) 
with stronger algorithms and/or longer keys. 

Document: A document can be any information 

3S which can be represented electronically or optically (e. 
g. an arbitrary bit stream). 

Key Degradation/Algorithm Degradation: The proc- 
ess whereby (he protectk)n afforded a document by en- 
cryption under a key toses effectiveness over time. For 

^ example^ due to factors such as improvements in com- 
puting speed and breakthroughs in cryptoanalysis, it is 
expected that a document securely encrypted today 
would be cracKable years later. This property could af- 
fect any cryptographic informatkMi, including digital sig- 

45 natures. This problem can be generalized to keyed and 
non-keyed cryptographic processes and artifacts, such 
as one-way hash algorithms. The security provided by 
these are also expected to diminish over time. 

LTSV: Long Term Signature Verification. The herein 

so described method and apparatus for verifying a digital 
signature after the certificates used for such verification 
have expired. 

LTSV client: The entity which requests/utilizes the 
services of the LTSV server. 

ss LTSV sen/er The entity which deivers the LTSV 
services. This does not imply, however, that this entity 
must be stand-alone component. 

LTSV submission: A request from an LTSV client to 
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an LTSV server to perform the necessary functions re- 
quired to enable reverification of a digital signature 
some time in the future (e,g. save PKl state). 

PKI: Public Key Infrastructure. Refers to all compo- 
nents, protocols, algorithms, and Interfaces required to 
deliver the capabilities to digitally sign and verify docu- 
ments. For purposes of clarity herein, a PKI does not 
include a service module for long term signature verifi- 
cation (LTSV sen/er), although in practice a PKI might 
be designed to encompass such a module. 

Signature Reverification: The re-creation of the dig- 
ital signature verification process after the original veri- 
fication. This specifically refers to the process associat- 
ed with the verification process, based upon the resto- 
ration of the previously saved PKI state. 

Signature Verification: The process by which a dig- 
ital signature, for a given document, is determined to be 
authentic ornot. 

Signature Verification Module: The module which Is 
responsible for performing the verification of digital sig- 
natures. 

Time stamp: A dtg'lal time stamp is an electronic 
indicator which associates the cun^ent date and time 
with a particular document. Time stamps are useful for 
proving that a document existed at a particular time. It 
is desirable that time stamps be secure, durable over 
time, and trusted by those using them. 

The discussion herein assumes an understanding 
of public key. digital signatures, and PKI infrastnjcture 
using X.509 certificates. Practical information concern- 
ing application of such techniques is considered to be 
welt ioiown to those skilled in the art. Background infor- 
mation may be found, for example, in B, Schnter, Ap- 
plied Crvptooraphv: Protocols. Algorithms, and Source 
Code inc . John Wiley & Sons. Inc. (1996); W. Ford, M. 
Baum. Secure Electronic Commerce . Prentice Hall PTR 
(1997); and in the X.509 v.3 specification ([X.509-AM] 
ISO/IEC JTC1/SC21, Draft Amendments DAM4tolSO/ 
lEC 9594-2, DAM 2 to ISOIEC 9594-6, DAM 1 to \Sa 
lEC 9594-7, and DAM 1 to ISOyiEC 9594-B on Certifi- 
cate Extensions, 1 December 1996). The system de- 
scribed herein may be built upon the X509 infrastruc- 
ture. 

The following discussion provides some back- 
ground on cryptographic techn'ques. Cryptographic al- 
gorithms can generally be divkled hto two categories: 
public key fe.p. RSA) and secret key (e.g. DES). Both 
types of algorithms transform plain text into cypher text 
using a key(s) for the encryption and decryption proc- 
esses. 

Both public key and secret key algorithms are con- 
sidered to be secure. One is not better than another in 
terms of security. The strength of each algorithm, In 
terms of it being cracked, is largely a function of the 
length of the key used. The primary distinguishing char- 
acteristic of publk: key, however, is that it uses two keys 
(one to encrypt and another to decrypt), while secret key 
algorithms use only one key (the same Icey is used for 



encryption and decryption). For this reason, secret key 
algorithms are sometime referred to as symmetrk: algo- 
rithms and publfc key algorithms are called asymmetric. 
One problem with secret key algorithms that a key 
s must be distributed between all parttelpants. This means 
that some secure channel must be available for the dis- 
tribution of the keys. 

In practtee. each entity in a public key-based system 
has a key pair, i.e. one private key and one public key. 
10 The private key is known only to its owner, the public 
key is known to all con-espondents. It is computationally 
inf easible to determine a private key from the public key 
The two primary services provided by public key 
cryptography are secure exchange of symmetric keys 
75 (by using public key techniques to encrypt a symmetric 
session key), and non-repudiation via digital signatures. 

Public key cryptography can be used to solve the 
key exchange pmblem associated with secret key algo- 
rithms by using this technology to encrypt the secret key 
under the public key of the recipient. It can then be de- 
crypted by the recipient using his/her private key. 

Digital signatures are possible by encrypting data 
with the private key of the signing entity. Any entity can 
decrypt it with the signer's publicly available public key 
and know that no one else could have encrypted It be- 
cause that private key is only known by that one individ- 
ual. This particular use of public key provides the non- 
repudiation service, which is a primary use of public key 
cryptography. A digital signature is very powerful notion, 
it generally exhibits the following characteristics: 

• Cannot be forged; 

• is independently verifiable; 

• Is not reusable or transferable to a different piece 
of data; and 

• Includes data integrity checks, allowing tamper-de- 
tectfon. 

The new sen/ices provided by public key cryptog- 
raphy do not come for free, however, because these 
services require the existence of a supporting public key 
infrastructure. The strength of a public key system de- 
pends upon the assurance that all participants know the 
public key of any entity with whom they wish to corre- 
spond. If a secure correspondence between a user and 
his/her public key cannot be maintained, then it may be 
possible to impersonate another entity or read encrypt- 
ed data intended for another. 

The standard solution to this problem is the issu- 
ance of a digital certificate (X.509 certificate) to each 
participant. This ceitificate securely binds its owner's 
name with his/her public key It is issued by a trusted 
third party, called a certrficalion authority (CA), and is 
signed by that OA, thereby making it tamper proof. Cer- 
tificates are issued for a limited period of time (start and 
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stop dates), during which the certiricate is considered 
valid A certificate is considered expired after the ending 
validity date. 

The public l^eys of entitles (which are embedded in 
the X.509 certificates) must be publicly available. The 
distribution or access mechanisms available are numer- 
ous. 

The secure operation of a public key infrastructure 
rests upon certain points of trust. Certainly each entity 
must trust its own CA. However, when a given PKI do- 
main is expanded to encompass relationships with mul- 
tiple C As, the number of points of trust are also expand- 
ed The trust placed in a particular end entity (Le. that 
entity's certificate or signature) is directly related to the 
trust relationships among the CAs which certify those 
entities. 

CAs can create trust relationships with other CAs 
by certifying each other. This can be a unidirectional 
trust relationship, whereby one CA can merely issues a 
certificate to another CA. just as a C A issues a certificate 
to an end user. Two CAs can also mutually agree to trust 
each other (bidirectional trust relationship) by issuing a 
cross-certificate - a special form of certiFicate which 
contain two individual certificates, one for each direc- 
tion. 

If two enl ities are in the same C A domain, then there 
is no concern with respect to C A trust because they both 
trust the same CA. This is not the case, however, when 
dealing with the scenario where entities which have 
been certified by different CAs attempt to conduct a se- 
cure transaction. The security of this transaction de- 
pends upon the trust between the CAs. f^ore generally, 
the security provided by the PKI depends upon the trust 
models embodied in the tmsl relationships among the 
various CAs whlc^ choose to trust one another. In con- 
crete terms, any change in these trust relationships can 
cause a signature verification to either succeed or fall. 

The preferred method and apparatus effectively ex- 
tend the time over which a digital signature can be ver- 
ified. i,e. well beyond the ex^ration of any or all of the 
certificates upon which that signature depends. They 
can be used lor any application domain where users 
want digital signatures to be used on long lasting docu- 
ments (e.g. contracts), and be independently verifiable 
years or decades after signing the document The pre- 
ferred embodiment of the invention provides two alter- 
native approaches to constructing a solution which de- 
livers long term signature verification (LTSV). 

Fig. 2 is a block schematic diagram illustrating a 
'save state" embodiment of the invention. This embod*. 
iment, largely entails the use of cryptographic informa- 
tion and techniques. Thus, an archive faclfity 20 is used 
to store a public key infrastructure (PKI) state 24, e.g. 
cryptographu: information, such as certificates and 
CRLS, in addition to the source document itself. For ex- 
ample, the LTSV client 25 requests the sendees of an 
LTSV server 26 to accomplish storage of such informa- 
tion. This step is shown as the "save state' step rn Fig. 



2. The PKI state information may contain either or both 
of cryptographlcally protected infonmatlon, such as cer- 
tificates and CRtjs, and information that is not crypto- 
graphlcally protected, such as the public key of a root 

s certification authority or policy information. 

This informatton comprises all that Is necessary to 
re-create the signature verification process at a later 
time. i.e. during the "restore state" step, for exantple, as 
requested by the LTSV client. It may also be desirable 

10 to store the source document separately from the cryp- 
tographic information (such as the signature, certifi- 
cates, and CRLs) for reasons of privacy. For example, 
a user may want to have control over the source docu- 
ment 

When a user wants to reverify the signature on a 
document, possibly years later, the LTSV sender 26 re- 
creates the precise state of the PKI at the time the doc- 
ument was originally submitted. The LTBV senrar re- 
stores the state, and the signature verification process 

20 28 executes the exact process it pedormed (or would 
have performed) years earlier. The time used as the ba- 
sis for re-creation of the signature verification process 
does not have to be the time of submittat Rather, the 
Time could be some other relevant time, such as when 

^ a document was signed by the originator or when il was 
verified by a recipient. ' 

Fig. 3 is a block schematic diagram illustrating a 
'save state' 'secure storage' embodiment of the inven- 
tion. This embodiment of the invention combines the 

30 strength of cryptography with the proven reeH'ience of 
(non-public key) technology and procedures currently 
associated with secure data stores. An example of this 
embodiment: 

ss • Saves the PKI state for future reverlficatlon (as de- 
scribed above in connection with Fig. 2); arid 

• Protects the PKI state intormatlon from intrusion by 
maintaining it in a secure storage facility which is 

40 protected by sen/ices, such as firewalls, access 
control mechanisms, audit facilities. Intrusion de- 
tection facilities, physical Isolation, and network iso- 
lation; and/or employing a cryptographs protection 
mechanism, for example using the LTSV sewer to 

45 sign the PKI state information or us'mg a keyed hash 
algorithm. 

In addition, other non-cryptographic features may 
be added to such approach to deliver a highly secure 
so and trusted LTSV solution, including, tor example utili- 
ties 30 for viewing the PKI state information (crypto- 
graphic as well as non-cryptographic) and visually mon- 
itoring the security of the system. These utilities can be 
used to provide visual evidence for purposes of dispute 
resolution. 

One enhancement to the secure storage approach 
herein disck^sed maintains certain evidence, such as 
certificate chains, in an archive. This Information need 
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not be used for actual reverification, but merely as sup- 
porting evidence in case of a di&pute. See A. Menezes. 
P. van Oorschct. S, Vanstone, Handbook of Applied 
CrvptoQraphv . CRC Press, pp. 583 (1996). for one man- 
ner in which this enhancement may be impJemented in 
the context of a notary sennce (discussed above). 

There are other embodiments of the inventk)n in 
which a hybrid LTSV solution could be constructed by 
combining cryptographic and non -cryptographic tech- 
niques. The best combination for a particular application 
domain depends upon the security requirements of the 
application(8), in combination with cost constraints. 

It Is presently preferred to employ the second em- 
bodiment of the Invention (discussed above) due to the 
cryptographic strength associated with its ability to rie- 
create the complete digital signature verification proc- 
ess, combined with the trust Instilled by more conven- 
tional techniques used tor providing secure storage, and 
In conjunction with audit and viewing facilities with which 
to view evidence and monitor the secure storage con- 
trols. In practice, the most useful embodiment of the in- 
vention for a particular application may be that which is 
the least expensive and which still meets the user or ap- 
plication requirements. 

Several issues related to the design of a system 
which implements LTSV are described below. Alterna- 
tives for the resolution of the issues are presented, as 
well as a discussion of the advantages and disadvan- 
tages associated with each alternative/ The best ap- 
proach to any given solution depends upon the security 
requirements of the application(s) using the LTSV sen/- 
ices, as well as the cost constraints. There is no best 
solution for all applications. 

When to Save the PKI State 

Signature reverification is preferably associated 
with a particular time because the outcome of this proc- 
ess could change, depending upon the state of the PKI 
(e,g. because of certificate revocations or the creation/ 
removal of cross certificates). There are numerous pos- 
sibilities with regard to when the PKI state should be 
saved, including: 

• At signature creation time. This approach is used 
when an individual wants to document the validity 
of his/her signature at the time it was created. This 
is the most accurate time to store the PKI stale be- 
cause it reflects the state at the time of signing, 
which is presumably the critical time in evaluating, 
the authenticity of that signature. Changes to the 
PKI state occur after that time, sonne of which could 
impact the outcome of a signature reverification. 
Therefore, saving of the PKI state at any time after 
signing introduces the possibility of inconsistencies 
between the signer's and recipient's perspectives 
on a signature's validity. 



• At signature verification time. This apofoach is uso- 
fut when a recipient wants to document the validity 
of a signed document received from another indi- 
vkJual. . 

• At archival time. When a user decides that a docu- 
ment should be archived for long term storage is 

. also an appropriate time to save the PKI state. 

• When expllcitiv requested. There may occur certain 
application specific document life cycle milestones, 
at which time the user may desire the PKI state to 
be saved for future reverification; 

'5 • Just before changes in PKI state (e.g. certificate 
revocation): This approach requires a tight integra- 
tion with the PKI because changes in the PKI must 
be monitored. 

20 The correct time at which to save the PKI stale is 
preferably determined by the constraints and needs of 
the application using the LTSV sen^ices. A robust LTSV 
solution is able to accommodate the needs of all (or 
most) applications in this respect. 

2S 

Contents of the PKI Stale. 

The exact composition of the PKI state varies some- 
what from one PKI vendor's product to another's, de- 

30 ponding upon the Implementation chosen by each ven- 
dor. Moreover, certain information is stored in a different 
format from one vendor to another. In addition, the con- 
tents of a PKI state may change over tirne as well, as 
new capabilities (and supporting data) are added to the 

35 system. Finally, the required contents of the PKI state 
may change from one application to another, depending 
upon the needs (e.g. level of security and legal require- 
ments) of each application. 

Notwithstanding these uncertainties, there are 

^ classes of PKI state infomr^tion which are candidates 
for saving. These classes include: 

• Certificate chain (list of certificates from one entity 
to another, including certification authorities (CAs) 

^ and the end entities). 

« CRLs (one for each CA in certificate chain). 
CA policy statements or identifiers. 

so 

• Attribute certificates. 

• Date and time. . 

ss • Trust inforntation (e.g., public key(s)orcertificate(s) 
of trusted root CA(s), policy constraints). 

Policy constraints are, for example, non-crypto- 
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graphic information stored within the LTSV archive. The 
public key of the trusted root CA may or may not be cryp- 
tographlcally protected. If it Is embedded In a certificate, 
then it is signed by the C A. However, it could just as well 
be an isolated public key, in which case it is unprotected 
by cryptography. 

II is possible that the items in the above list may not 
be supported or available from certain PKI Implementa- 
tions. Further, the PKI state from another implementa- 
tion might include some additional data. Therefore, the 
list above is only an example of what might be consid- 
ered Important pieces of PKI state information, given the 
current state of the technology. An implementation of an 
LTSV service is preferably lied to the implementation of 
a specific PKI until such time as the technology evolves 
and comprehensive standards emerge. 

How to Store the PKI State. 

Storage of the PKI state is preferably accomplished 
in either of two general ways: 

• Store all of the PKI state relevant to each document 
separately; and 

• Store the PKI state centrally, and only store refer- 
ences -to the PKI state information with each docu- 
ment. This approach enables storage efficiencies 
by eliminating the redundant storage of PKI state 
infonnation over multiple documents. For example, 
given two documents submitted to the LTSV server 
at about the same time, rt is possible that the CRLs 
contained in the PKI state are exactly the same for 
tx>th submissions. Central storage of this Intoima- 
tion allows the LTSV server to store this (nformatbn 
only once. 

The storage requirements for the save state solu- 
tion for LTSV may be quite large, depending upon the 
size of the certificates, the length of the certificate chains 
and - more importantly - the size of the CRLs. The 
choice of storage technique may have a great impact 
on the total data storage requirements. It is clearly un- 
desirable to store massive CRLs with every document 
that is stored tor long term archival and possible future 
reverificatlon. For this reason, the second altennative 
listed above is presently considered to be the preferred 
approach. 

However, this second approach may present cer- 
tain difficulties in applications where the LTSV server Is 
an entirely separate component from the PKI, and 
where support of multiple PKIs is a primary design goat 
of the LTSV server. In this case, it woukJ be advanta- 
geous for the PKI state to remain opaque to the LTSV 
server, thereby providing ease of support of multiple PKI 
vendors. Given that what constitutes the PKI state for 
one vendor may be different for another vendor, it is de- 
sirable to maintain an opaque interlace between the 



LTSV server and the PKI. On the other hand, storage 
efTiciencies can be derived only if the LTSVsenrer is in- 
formed about the contents and format of the PKI state 
information. These conflicting requirements - accepla- 
s ble storage size and opaqueness - pose a challenge 
for the design of an LTSV service. 

Some of the possible alternatives are listed below: 

• Keep Ihe interface opaque and store the PKI state 
70 as it currently exists (full certificate chains and 

CRLs). This option focuses entirely on the opaque- 
ness requirement, and sacrifices the data size re- 
quirement The prinnary advantage of this solution 
is simplidly and qutek deployment. 

IS 

• Remove the opaqueness requirement by making 
the PKI state visible to the LTSV sen/er. This allows 
the LTSV server to manage the certificates and 
CRL^ manually - thereby avoiding duplication of 

^ these objects in the data store. This solution poten- 
tially sacrifices the ease of multi-vendor support at 
the expense of achieving efficient storage. 

• C€»npromise by making the CRLs visible to the 
25 LTSV sender, where other PKI state informatkxi is 

opaque. This solution is interesting because it ts 
probable that the CRLs are the largest piece of data 
comprising the PKI state. Because CRLs are stand- 
ard across nearly all PKIs, the visibility should not 
30 pose a problem in terms of multi-vendor support. 
This solution address both of the requirements, but 
does put the burden of management of the CRL^ 
onto the LTSV sender. 

^ • An alternative embodiment of the inventbn pro- 
vides a variation on the solution above that breaks 
up the PKI state into multiple pieces, each of which 
is opaque. The PKI indcates which of these objects 
is common across multiple signed documents (e.g, 

40 CRLs and certificates). The PKI labels these ob- 
jects with unique handles (identifiers), thereby al- 
towing the LTSV server to store these objects and 
retrieve them efficiently when needed for signature 
reveritication - all the white maintaining the 

4S opaqueness of these objects. 

• Encourage PKI vendors to make concise crypto- 
graphtcally protected assertions about the state of 
revocation, as an alternative to using CRLs. (For ex- 

^ ample, Cf^s indicate who has been revoked. It 
would be more efficient if the PKI could make a 
statement that a certificate has not been revoked at 
a given point in time. This could eliminate the need 
for storing CRLs.) This approach is non-standard, 

ss but acceptable because these PKI -generated as- 
sertions are not seen by any application outside the 
PKI. A major benefit of this approach is that the 
opaqueness of the state is presented whNe some of 
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the storage inefficiencies of the state information 
are removed. 

For cases where the LTSV server is dedicated to a 
particular PKl, it is preferred to create a close integration 
between the two components, thereby allowing the 
LTSV serv^er to know about the content and format of 
the PKl state infornnation. and store it in tlie most effi- 
cient manner possible. For cases where the LTSV send- 
er must be insulated from the PKl (e.g for portability 
across multiple PKIs), one of the options listed above 
(with the possible exception of the first two) may be 
used. 

Location of Source Data. 

The source data associated with an LTSV submis- 
sion can be stored either by the client or by the LTSV 
server itself. Some LTSV clients do not choose to submit 
clear text to the LTSV sender for storage because of con- 
cerns over privacy. (Privacy of the channel between the 
LTSV client and the LTSV sen/er can be achieved by 
having the client encrypt the submission under the pub- 
lic key of the LTSV sender.) A submission to the LTSV 
may be encrypted, such that the LTSV is not able to de- 
crypt iL That is acceptable with the LTSV server. How- 
ever, the client must determine how to decrypt the sub- 
mission. 

Given that the LTSV server views the source data 
as a bit stream, it is possible that the message could be 
encrypted by the LTSV client before submission. (The 
fact that a general purpose LTSV server treats the 
source document as a bit stream does not preclude the 
possibility of implementing an application specific LTSV 
server that is aware of the contents of the submitted da- 
ta) The LTSV sen/er treats the encrypted data as the 
source. Such prior encoding may be sufficient for some 
applications' needs for privacy. In this case, however, 
either the client must maintain the decryption key, or the 
key must be divulged and stored by the LTSV sender 
(which is probably not acceptable). 

Alternatively, the LTSV client may submit a mes- 
sage digest (resulting from a one-way hash function) as 
the source document The client, in this case, is respon- 
sible for maintaining the real source document. If the 
source document is stored by the client, then only the 
PKl state rnformatton is stored In the LTSV sen/er's ar- 
chive (along with some reference to the source docu- 
ment or the submitter). 

Whether the source data is stored by the client or 
the LTSV server, it must be produced if and when a 
reverification of that document is required. It is a re- 
quired component of any elgnature verification process. 

Key and Algorithm Degradation. 

If cryptographtcally encoded information (e.g. digit- 
al signatures or encrypted data) is stored for a significant 



period of time, the Issue of key and algorithm degrada- 
tion must be addressed, i.e. the probable loss In effec- 
tiveness of a cryptographic key or algorithm over time. 
Although signed documents are expected to be sealed 
5 securely with strong cryptographic algorithms, the 
strength of an algorithm and associated key length de- 
creases over time with the advent of faster computers 
and new developments in cryptoanalysis. It is expected 
that cryptographic algorithms and key lengths have lim- 
ited life spans. It Is generally acknowledged that they 
should be examined, modified, and/or replaced at peri- 
odic inten/ais. This legitimate security concern irKreas- 
es with the length of lime for which a document is valid, 
and it becomes a very serious threat as the time span 
approaches multipfe decades. 

For example, a digital signature performed today, 
using RSA and a 512-bit key, is considered very strong 
(ie. it would take years to forge It). But, it is also expect- 
ed that this same signature may be easily forgeable 
within ten years or so. This is because of the Increased 
ability to search the key space faster (and thereby find 
the key used to sign the message) with newer comput- 
ers or computing techniques. Similarly, there may con- 
tinue to be developments in techniques lor factoring 
large prime numbers (the difficulty of whteh Is the basis 
for the strength of the RSA algorithm). It is reasonable 
for both of these abilities to improve over time (although 
the pace of these changes is less certain). 

It is, therefore, prudent to protect cryptographically 
encoded documents from this threat when those docu- 
ments must live beyond a few years. This is the case 
with the documents expected to be submitted to the 
LTSV server, and especially so when using the save 
state approach herein disclosed. Hence, the LTSV facil- 
ity should address this problem. Not only must the 
signed documents stored in the archive be protected 
from this threat, but alt other cryptographic data or meta- 
data stored in the archive should be protected. (The 
cryptographic data primarily include keyed information. 
That is, any information that is signed or encrypted with 
a private key. Such intonnation may also Include non- 
keyed cryptographk: data, such as the output from a 
hash algorithm, such as hAD5.) This data could also in- 
clude such items as certificates and GRLs, which are, 
themselves, digitally signed by the issuing CA. 

There are any number of ways that the LTSV facility 
addresses this problem. For example: 

• Periodically countersign all data In need o1 crypto- 
graphic refresh through ttie use of nested signa- 
tures. Under this approach, the LTSV server effec- 
tively refreshes the cryptographic strength of the 
data by signing it with successively bnger keys (or 
stronger algorithms) every few years. Each counter 
ss signature has the effect of locking in the crypto- 
graphic strength of the enclosed signature(s), 
thereby extending the cryptographk: life of the en- 
closed document. This countersignature is prefera- 



15 



£0, 



ss 



30 



3S 



40 



AS 



8 



15 



EP0 892 521 A2 



16 



biy performed by the LTSV server using a key 
owned by that server. Performance shortcuts may 
be required to avoid the costly unraveling of signa- 
tures at reverlfication time, or the potentially time 
consuming task of countersigning every document 
In the archive. Such shortcuts include, for example, 
removing a prevbus countersignature before ap- 
plying a new one. or countersigning the entire ar- 
chive or ponkms thereof instead of each Individual 
document. 

• A modification of the cryptographic approach sug- 
gested above provides for countersigning the infor- 
mation in the archive once, but with an extremely 
long key, Le. a key which is expected to be unbreak- 
able tor decades or more. This eliminates all need 
for countersigning. This may be merely a theoretical 
solution because finding an algorithm and key 
length which is secure for that long is impossible to 
predicl. Therefore, there is still a need lo provide 
some backup mechanism, just in case the original 
algorithm were cracked, for example. 

• Protect the cryptographic information In the archive 
by insulating the archive itself, rather than the indi- 
vidual documents contained in the archive, thereby 
eliminating the need for a cryptographk: solution. In 
this approach, the archive is protected via access 
controls and other procedural controls. If the ar- 
chive can be effectively insulated from intrusksn and 
modificatkm, then key degradation is not an issue 
and cryptographic refresh is not necessary. 

• Use a time stamp facility to seal the cryptographic 
information in time. Such a facility is expected to 
provide all of the necessary characteristk:s required 
for solving the key degradation problem. This time 
stamp facility coukj use one of the techniques listed 
above, or it couM even be an Independent service 
(see below for a discussion of time stamping). 

Relationshp to Time stamping. 

A secure and comprehensive LTSV solution prefer- 
ably includes an association with a time stamping mech- 
anism. For long term verification of digital signatures. It 
Is often necessary to know the time at whk:h particular 
events occurred (e.g. time of signing or verifying a sig- 
nature) to determine if a document was valid at that spe- 
cific time. If there were uncertainty concerning when a 
document was signed, then the later reverification of 
that document could be compromised because of the 
uncertainty of when it was signed. 

Fig. 4 is a flow d'egram that provides two alternative 
scenarios that illustrate the applicability of time stamps. 
• In scenario 1: 

• Alice signs a document at time T1 . and sends it to 



Bob (140). 

• Alice*s certificate is revoked at time 12 (142). 
s • Bob verifieis Alice's signature at time T3 (144). 

In scenark) 2: 

• Alk;e's certifk:ate is revoked at time Tl (1 50).. 

10 

Alk:e signs a document at time T2, and sends it to 
Bob (152). 

• Bob verifies Alice's signature at time T3 (154). 

IS 

When Bob performs the verifbatkin (at time T3). he 
does not know when Alice signed the document. This is 
critical, because if Alice's key (certificaie) were revoked, 
before signing the message, then the signature veriflca- 

^0 tion by Bob should lail, and Bob should not trust the con- 
tents of the message. If. on the other hand, the revoca- 
tion occurred after the act off signing, then the signature 
can be presumed to be valid and trustworthy. For smrt- 
plicity, this example does not consider the complicating 

2S Issue ol CRL latency, Le. the time between the initiation 
of certificate revocation and the lime when this informa- 
tion becomes available on a CRL. 

This example demonstrates the need for a secure 
and trusted time stamp mechanism in the domain of dig- 

30 ital signatures. The mere recording of the current date 
and time when creating a digital signature is not suffi- 
cient for most appiicat'ron because the source of that 
lime may not be trusted by the recipient. The impact, 
however, also applies not only to the short term sigrta- 

3S ture verification process, but also to the long term veri- 
fication of digital signatures. Given the example above, 
the LTSV sender could save the PKI state (at time Tl ) 
associated with scenark) 1 or scenario 2 (or both). The 
outcome of a signature verificatkm on this message 

40 years later is greatly affected by the PKI state used for 
this verification process, as well as the target time for 
the verification. 

The problem highlighted above demonstrates the 
preference that the LTSV service to be cognizant of 

45 time. It should: 

• Be able to determine in a secure fashion the time 
at which a document was originally signed; 



so • Be able to re-create accurately the PKI state which 
was active at a target time in the past; 



ss 



Be able to determine the current date and time ac- 
curately; and 

At a minimum, save the PKI state associated with 
a particular target time. 
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These requirements establish the preference tor 
the integration of a time stamp facility with the signing 
and verification (and reveriftcation) process. When a 
document is signed, il is also preferably time stamped 
to document in a secure fashion the precise moment at 
which that event occurred. The LTSV service should 
know the time for which the PKI state is to be saved, be 
sure to save the appropriate state (the state active at 
the target time), and execute its signature reverification 
process in the context of the correct time. 

tJsaoe Scenarios. 

Figs. 5a-5c provide block schematic diagrams that 
illustrate three long term signature verification usage 
scenarios. 

In scenario 1 . a client (EntityA) 50 submRs a docu- 
ment to a LTSV facility 52 lor long term signature verifi- 
cation. This is a simple case where EntityA is interested 
in documenting that it possessed some piece of infor- 
mation. 

In scenario 2. Entity B 56 receives a document from 
EntityA 54 and submits that document to the LTSV fa- 
cility S8. In this case, EntityB wants to document that It 
received some information from EntityB. 

In scenario 3, EntityA 60 sends the same document - 
to EntityB 64 and to the LTSV facility 62. This case rep- 
resents a carbon copy feature, whereby EntityA can 
document the infomnation it sent to EntityB by addition- 
ally filing It with the LTSV facHity. 

Each of the scenarios described above raises is- 
sues with respect to encryption, private key access, and 
trust models. 

Encryption and Private Key Access. 

A document can be encrypted and/or signed. Ide- 
ally, the LTSV facility accepts any such document. This 
raises a problem, however, with respect to how the 
LTSV module works with respect to the encryption. 
When encrypting under a publfc key system, the docu- 
ment is effectively encrypted under the public key of the 
recipient, thereby guaranteeing that the recipient (the 
possessor of the corresponding private key) is the only 
entity which can decrypt the Information. (For purposes 
of this discussion, interaction with symmetrk: keys and 
algorithms is ignored.) 

When applying this principle to scenario 1 , it is clear 
that if the signed message is also encrypted, then it 
could be encrypted under the public key of the LTSV 
module . This allows the LTSV component to unwrap the 
signed document and presen/e il for long term verifica- 
tion. This is a useful feature because It provides confi- 
dentiality between EntityA and the LTSV service. This 
scenark) does not preclude the possibility that the 
source document sent signed and encrypted to the 
LTSV module could Itself be encrypted under a key 
known only to EntityA. That Is, it is not necessary that 



the LTSV have access to the plain text veislon of the 
source document. The LTSV module treats that encrypt- 
ed document as the source. If EntityA does decide to 
encrypt the document first under a secret key before 
s submitting the document to the LTSV sen^ice, then it is 
the responsibility of EntityA to maintain possession o( 
that key if and when decryptron of that document is re- 
quired. 

In Scenarb 2, if the message from EntityA to EntityB 
10 is encrypted (under the public key of EntityB) and then 
fon^rarded - unchanged - to the LTSV service by Enti- 
tyB. then it is unreadable by the LTSV component be- 
cause It does not possess the private key required to 
decipher and unwrap the enclosed signed document. 
'5 This unwrapping (deciphemr>ent) is essential for the 
LTSV module to do its job. 

There exist several alternatives for addressing this 
problem: 

£0 • Allow the LTSV facility to have access to EntilyB's 
private key; 

• Do not alk>w EntityA to send encrypted documents 
to EntityB; or 

2S 

• Have EntityB strip off the privacy aspect of the 
signed and encrypted document received from En- 
tityA. Because EntityB wants to presen/e EntttyA's 
signature on the document, and be able to verify ft 

30 at a later time, this stripping process can not alter 
the validity of the signature. EntityA can then either 
send the stripped (Le. plain text) document to the 
LTSV sen/ice. or it can re-encrypt it (still presen/ing 
the original signature by EntityA) under the public 

as key of the LTSV module. 

The latter approach above is presently the preferred 
approach. The first approach above raises significant 
security concerns because it requires distribution of an 
40 entity's private key. TTie second approach above is un- 
acceptably restrictive on the usage of the system. 

Trust. 

45 Digital signature verification is always performed 
between two (and only two) entitles. The verification 
process Is based upon (among other things) the trust 
relaiionship(s) in place between those two entities - the 
originator (signer) and the recipient (verifier). 

so Fig. 6 is a block schematic diagram that ilhjstrates 
trust between two entities according to the invention, in 
this sftuatbn, EntityA 70 has been issued a certificate 
by CA1 72, EntityB 74 has been issues a certificate by 
CA2 76, and OA's 1 and 2 have been cross certified. (A 

ss cross-certificate is a special type of certifteate which in- 
dicates mutual trust between two CAs.) The resulting 
trust model sets up a path of trust between EntityA and 
EntityB, enabfing them to verify digitally signed docu- 
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merits from one another successfully. (A trust rrtodel is 
comprised of the trust relationships among PKI entities 
(CAs and end users), emtsodied by the certificates and 
cross-certificates issues among these entities, as well 
as the underlying policies which enable this trust.) Note 
that If any of the three paths in this model were not In 
place, then sufficient trust would be lacking for the suc- 
cessful exchange of digitally signed messages between 
the two end parties. Signature verification would fail if 
any entity in this path is not trusted. 

This trust path is commonly referred to as the cer- 
tificate chain because it is composed of the certificates 
between the two entities. When considering the save 
state approach to iong term signature verification, it is 
this entire trust path (among other things) which must 
be archived as part of the PKI state for later signature 
reverificaiion. Moreover, the trust path stored by the 
LTSV facility must contain the relevant trust information 
existing at the time of the request, not at some other 
time (belore or after) where the Irusl relationships may 
be different between the entities. For example, a cross 
certiTicate between to CAs could either be created or re- 
moved at some point in time. This could effect the trust 
between two entities and affect the outcome of a signa- 
ture verification. 

As discussed above, the time associated wHh the 
existing trust model between two entities is extremely 
important to the LTSV facility, but there are also ramifi- 
cations with respect to how the LTSV module works - 
specifically, what trust information Is needed and stored 
by the LTSV component for later signature verification. 
This gets complicated when the LTSV component is In- 
cluded, which may or may not be trusted (via some trust 
path) by some entities. 

Consider the three scenarios illustrated in Figs. 5a- 

5c: 

Scenario 1 is fairly straightfonvard. There are only 
two entitles involved. The trust path stored by the LTSV 
facility is the path between those two parties (EntityA 
and LTSV). It is assumed that trust exists between these 
entities, otherwise EntHyA would not submit a request 
to that service. 

Scenario 2, however, raises certain issues. When 
EntityB sends a request to the LTSV service, what sig- 
nature does EntityB want to later verify? Most likely. En- 
tityB wants to reverify EntityA's signature at a later time 
- ft wants the LTSVsenrice to document that the signed 
document received from EntityA was valid (contained a 
valid signature) at the time it was received. This raises 
two general questions: 

• Whether the LTSV sen/ice is tmsted by EntityA. It 
can be assumed that the communicating parties 
(EntityA with EntityB, and EntityB with the LTSV) 
have developed some trust between themselves. 
But in this case, it is possible that there exists no 
trust path between EntityA and the LTSV compo- 
nent. 



« The tnjst path that is to be stored by the LTSV fa- 
cility There exist three possible trust paths which 
can be stored by the LTSV. Le. the path between 
Entities A and B: the path betweeri EntityB and the 
5 LTSV component itself; and the path between Enti- 
tyA and the LTSV component, rf it exists. 

. Fig. 7 Is a block schennatic diagram that illustrates 
a long term signature verification trust model. Given see- 
to nario 2^ where EnthyB 84 submits a signed document, 
rece'rved from EntityA 80, to the LTSV component BB, 
the LTSV can save the trust model embodied in the orig- 
inal signed document (EntityA 80 -» CA1 82 CA2 86 
EntityB 84). Later verification of this signature recre- 
t5 ates the verification process originally performed by En- 
tityB when it received this document from EntityA. It. 
however, the PKI state stored by the LTSV sen/ice were 
to contain only the trust path between the iBubmitter and ~ 
the service (EntityB 84 -> CA2 86 -> CAS 90 -> LTSV 
20 88). then reveriricalion of the original document, as orig- 
inally periormed, is impossible. In fact, this is exactly the 
paradigm described in scenario 1 , where the trust path 
between the submitter and the LTSV are of interest 
The above discussbn reveals that there are good 
2S reasons for the LTSV connponent to be able to store ei- 
ther trust path, depending upon the requirements of the 
client. 

in scenario 2, the LTSV would most likely store the 
trust path corresponding to the message from EntityA 
30 to Ent'rtyB (to reverify the signed docurnent from EntityA 
to EntityB). In scenario 1 , the LTSV would store the trust 
path corresponding to the submission Itself - from En- 
tityA to the LTSV. 

Similarly, scenario 3 represents a case where flex- 
es ibility in wh^h trust path(s) to store is required. In this 
case. EntityA's submission to the LTSV facility nrmy be 
with the intent to either reverify its correspondence with 
EntityB. or to reverify the submission itself (between En- 
tityA and the LTSV). In tact, both trust paths may be of 
40 use to the client The requirements on the LTSV are de- 
termined by the business of the particular application 
being deployed. For this reason, the interface to the 
LTSV preferably supports the ability of the client to Indi- 
cate the needs In terms o1 trust paths as it impacts the 
<s requirements for later reverification. 

The disclosures In United Slates patent appricatkm 
no 08/892.792, from which this application claims prior- 
ity, and in the abstract accompanying this applteatibn 
are incorporated herein by reference. 

so 

Claims 

1 . A method of enabling long term verification of digital 
ss signatures, comprising the steps of: 

submitting a source document or digest thereof 
to a signature verification entity; and 
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using an archive facility to store a public l<ey 
infrastructure (PKI) state relative to sard docu- 
ment at a selected archival time. 

2. A method as In claim 1 . comprising the steps of: 

usmg said archived PK) state to re-create said 
PKI state relative to said document at a select- 
ed time after a certificate associated with said 

signature has expired; 

wherein the time over which a digital signature 
associated with said document can be verified 
is extended beyond expiration of any or all of 
any certificates upon which that signature de- 
pends. 

3. A method as in claim 1 or 2 comprising the step of: 

storing said source document separately from 
aniy associated cryptographic infonmation. 

4. A method as in claim 1 , 2 or 3 wherein the selected 
archival time used as the basis for subsequent re- 
creation of a signature verilication process is the 
time of said source document submittal; 

is the time when said source document was 
signed by its originator; or in the time when said 
source document was verified by a recipient. 

5. A method as in any preceding claim, comprising the 
step of, 

protecting said PKI state information from intrusion 
by maintaining it in a secure storage facility prefer- 
ably comprising of at least one of a firewall, access 
control mechanism, audit facility, intrusion detection 
facility, physical isolation and network isolation; or 
protecting non-cryptographic PKI state infonnation 
from intrusion by protecting it in an archive via any 
of a signature and keyed hash algorithm. 

6. A method as ri any preceding claim comprising the 

step of: 

providing utilities for viewing said PKI state informa- 
tion and for visually monitoring system security. 

7. A method as in any preceding claim« wherein class- 
es of PKI state information may include one or more 
of certificate chain from one entity to another, In- 
cluding certification authorities (CAs) and the end 
entities; certificate revocation lists (CRLs), one for 
each CA in certifk:ate chain; certificate practice 
statements; attribute certificates; polk:y constraints; 
trust information; and date and time. 

8. A method as in any preceding claim, comprising the 
step of: 

periodically countersigning all data in need of cryp- 
tographk; refresh through the use of nested signa- 
tures and/or countersignhg information In said ar- 



chive facility once with an extremely long key. 

9. A method as in any preceding claom, corriprising at 
least one of the steps of: 

5 

protecting said archive facility itself, rather than 
individual documents contained in sakj archive; 
and 

employing a cryptographk^ protection mecha- 
10 nism at said signature verification entity. 

10. A method as in any preceding claim, comprising the 
step^: 

using a time stamp facility to seal cryptographic rn- 
iB (ormation in time. 

1 1 . Apparatus for long term verification of digital signa- 
. ture, comprising: 

^ a source document; and 

an archive facility for storing a public key infra- 
structure (PKI) state relative to said document 
at a selected archival time. 

2S 12. Apparatus as in claim 11, comprising: 

either of a signature and a keyed hash system 
for protecting non-cryptographic PKI state informa- 
tion from undetected nxxJification, wherein saki 
noncryptographic PKI state information is main- 

$0 tained in an archive. 
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(54) Method and apparatus for long term verification of digital signatures 



(57) The time over which a digital signature can be 
verified Is extended well beyond the expiration cl any or 
all of the certificates upon which that signature depends. 
In a "save state' approach, an archive lacility is used to 
store public key infrastructure (PKI) state, e.g. crypto- 
graphic information, such as certificates and certificate 
revocation lists (CRLs)> in additbn to non-cryptographic 
information, such as trust policy statements or the doc- 
ument itself. This infonnatbn comprises all that is nec- 
essary to re-create the signature verification process at 
a later time. When a user wants to verify the signature 
on a document, possibly years later, a long term s'^na- 
ture verificatkm (LTSV) server re-creates the precise 



state of the PKI at the time the document we» originally 
submitted. The LTSV server restores the state, and the 
signature verification process executes the exact proc- 
ess it performed (or would have performed) years ear- 
lier. Another embodiment of the invention combines the 
strength of cryptography with the proven resilience of 
(non-pubtic key) technology and procedures curreritiy 
associated with secure data stores by saving the PKI 
state for future verification; and protecting the PKI state 
tnformatbn from intrusion by maintaining it in a secure 
storage facility which is protected by sen/ices, such as 
firewalls, access control mechanisms, audit facilities, in- 
trusbn detection facilities, physical isolation, and net- 
work isolation. 
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